Method for generating a human likeness score

ABSTRACT

One embodiment of the invention is a method utilizing a CAPTCHA to generate a human likeness score including blocks: a) receiving a user solution to the CAPTCHA; b) receiving a user interaction pattern descriptive of an interaction undertaken by the user, through a graphical interface of the CAPTCHA, to achieve the user solution; c) determining the accuracy of the user solution; d) comparing the user interaction pattern against an interaction model generated from interaction patterns of previous users; e) calculating the human likeness score based upon the determination of block c) and the comparison of block d), wherein the human likeness score lies within a continuum of human likeness scores.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/734,806, filed Jun. 9, 2015, and titled “Method for Generating aHuman Likeness Score,” which is a continuation-in-part application ofU.S. patent application Ser. No. 14/292,266, filed on May 30, 2014, andtitled “Method for Generating a Human Likeness Score,” now U.S. Pat. No.9,501,630, which is a continuation of U.S. patent application Ser. No.13/411,071, filed on Mar. 2, 2012, and titled “Method for Generating aHuman Likeness Score,” now U.S. Pat. No. 8,776,173, which claims thebenefit of U.S. Provisional Application No. 61/467,124, filed Mar. 24,2011, and titled “Method for Generating a Human Likeness Score,” each ofwhich is incorporated by reference herein in its entirety.

TECHNICAL FIELD

This invention relates generally to the human verification field, andmore specifically to a new and useful method for generating a humanlikeness score in the human verification field.

BACKGROUND

Many websites and applications apply various techniques and methods todiscern a human user from automated software prior to granting certainaccess or privileges to the user. Distinction between a human user andautomated software is often desired, such as when a user is signing upfor a service, when a user is attempting to log in to a service oraccount, when a user is participating in an online poll or forum, orwhen a user generating an online post. Many websites employ CAPTCHAs(Completely Automated Public Turing tests to tell Computers and HumansApart) to achieve such functionality. A common CAPTCHA includes adepiction of distorted text images and requires transcription of thedistorted text image. However, websites, applications, and otherservices that implement such CAPTCHAs risk inadvertently driving awaytraffic by legitimate users (i.e. non-spamming humans) while providingonly minimal protection against automated software and human spammers.Alternatively, websites, applications, and other services that fail toimplement some such security feature risk security breaches.

Therefore, there is a need in the human verification field to create anew and useful method for generating a human likeness score indicativeof the legitimacy of a use. This invention provides such a new anduseful method.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a flowchart representation of a method of the preferredembodiment of the invention;

FIG. 2 is a schematic representation of the elements of a CAPTCHA of thepreferred embodiment;

FIGS. 3A-3H are schematic representations of exemplary game-likeCAPTCHAS of the preferred embodiment;

FIG. 4 is a flowchart representation of a system implementation of thepreferred embodiment;

FIGS. 5A, 5B, and 5C are schematic representations of a CAPTCHA of thepreferred embodiment at various time intervals;

FIGS. 6A, 6B, and 6C are schematic representations of a CAPTCHA of thepreferred embodiment at various time intervals;

FIGS. 7A, 7B, 7C, and 7D are schematic representations of a CAPTCHA ofthe preferred embodiment at various time intervals;

FIGS. 8A and 8B depicts a decision tree for completing a block of thepreferred embodiment;

FIGS. 9A-9E depict a user input path, an average user input path, thenoise in the user input path, noise in a typical human input path, andnoise in a typical automated software input for a block of the preferredembodiment;

FIGS. 10A-10C depict a user input path geometry, a typical human inputpath geometry, and a typical automated software input geometry for ablock of the preferred embodiment; and

FIG. 11 is a flowchart representation of one variation of the method.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionis not intended to limit the invention to these preferred embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

As shown in FIG. 1, the method S100 utilizing a CAPTCHA to generatehuman likeness score, the CAPTCHA provided through a graphicalinterface, includes the blocks of: receiving a user solution to theCAPTCHA Silo; receiving a user interaction pattern descriptive of aninteraction undertaken by the user, through the graphical interface, toachieve the user solution S120; determining the accuracy of the usersolution S140; comparing the user interaction pattern against aninteraction model generated from interaction patterns of previous usersS140; and calculating the human likeness score based upon thedetermination of block S130 and the comparison of block S150, whereinthe human likeness score lies within a continuum of human likenessscores S160. The method S100 may further include the blocks of:comparing the human likeness score to a threshold likeness score toverify that the user is human S170 and/or adding the user solution to acatalog of user preferences S180. The method S100 may also include theblocks of: receiving a request for a CAPTCHA; and fulfilling the requestfor the CAPTCHA by generating certain details of the CAPTCHA and/or thecomplete CAPTCHA S190.

As shown in FIG. 1, the method S100 may also be a method utilizing aCAPTCHA to verify that a user is human, the CAPTCHA provided through agraphical interface, including the blocks of: receiving a user solutionto the CAPTCHA Silo; receiving a user interaction pattern descriptive ofan interaction undertaken by the user, through the graphical interface,to achieve the user solution S120; receiving user data that is distinctfrom the CAPTCHA and the user interaction pattern S130; determining theaccuracy of the user solution S140; comparing the user interactionpattern against an interaction model generated from interaction patternsof previous users S150; analyzing the user data for automated software(or human spammer) indicators S155; calculating a human likeness scorebased upon the determination of Block S140, the comparison of Block 150,and the analysis of Block S155, wherein the human likeness score lieswithin a continuum of human likeness scores S160; and comparing thehuman likeness score to a threshold likeness score to verify that theuser is human S170.

The method S100 is preferably performed by a server in communicationwith a publisher configured to present the CAPTCHA to the user via ahost website or application. The publisher may present the CAPTCHA tothe user via: a website; a mobile application; a web- orapplication-based forum; an online, desktop, or application-based emailclient; an online gaming site or service (e.g., Xbox live); or any othersuitable site, service, or application configured to provide data to theuser and to receive an input from the user. The site, service, orapplication through which the CAPTCHA is presented to the userpreferably executes on a digital device incorporating a digital display,such as an automotive console, a desktop computer, a laptop computer, atablet computer, a television, a radio, a desk phone, a mobile phone, asmartphone (e.g., an iPhone), a PDA, a personal navigation device, apersonal media player (e.g., MP3 player, iPod), a camera, a gamingconsole or controller, a remote control, a watch, or a heads-up display(HUD). The publisher and/or server preferably communicate(s) with thedigital device via a communication channel, such as Wi-Fi, LAN, 3Gcellular, 4G cellular, Ethernet, or other cellular or internetconnection, or via any other analog or digital communication channel.The transfer of data, including details of the CAPTCHA, user data, theuser solution, the user interaction, and the human likeness score,between relevant parties is depicted in FIG. 4.

In one variation, the server generates the CAPTCHA, including thecontent in and instructions of the CAPTCHA, and sends the CAPTCHA to thepublisher, wherein the publisher then presents the CAPTCHA to the user.In a second variation, the server generates the CAPTCHA, including thecontent in and instructions of the CAPTCHA, and directly presents theCAPTCHA to the user (e.g., through a host website or application)following a request therefor from the publisher. In a third variation,following a request for a CAPTCHA from the publisher, the serverspecifies specific details of the CAPTCHA (i.e. less than the entiretyof the CAPTCHA) and sends the details to the publisher, wherein thepublisher then assembles the CAPTCHA, based upon the details, andpresents the CAPTCHA to the user. In a fourth variation, the CAPTCHA isgenerated, at least in part, by the publisher (e.g., by selecting aCAPTCHA format from the set of generic CAPTCHA formats shown in FIGS.3A-3H and assigning details to the CAPTCHA); in this variation, theserver may solely function to analyze the user solution and the userinteraction to generate the human likeness score (i.e. BlocksS110-S160). However, the server and/or the publisher may functiontogether or separately to create the CAPTCHA and present the CAPTCHA tothe user.

The method S100 of the preferred embodiment utilizes a CAPTCHA, a“Completely Automated Public Turing test to tell Computers and HumansApart,” to generate the human likeness score S160 and/or to verify thatthe user is human S170. The CAPTCHA is preferably presented to the userprior to granting additional access or information to the user, prior tocompleting a transaction, prior to generating a user account, and/or forany other reason necessitating verification that the user is human (ornot automated software or a human spammer).

As shown in FIG. 2, the CAPTCHA preferably includes a graphicalinterface 193; the graphical interface 193 may be, effectively, a “box”presented to the user on the digital display of a digital device of theuser, wherein information, symbols, and/or other objects relevant to theCAPTCHA are presented therein and the user employs the information,symbols, and/or other objects to complete the CAPTCHA. However, thegraphical interface 193 may be of any other form defining any otherinput area. The graphical interface 193 may be depicted within a webbrowser or application directly, or may be presented within a pop-upwindow or separate application, though the graphical interface 193 maybe presented to the user in any other way.

As shown in FIG. 2, an object 194 is preferably depicted within thegraphical interface 193 of the CAPTCHA. At least one characteristic ortrait of the object is preferably haphazard, randomly generated,pseudorandomly generated, or otherwise seemingly irregular in selectionor assignment. (Because the server fulfilling the method S100 mayincorporate software incapable of generating a truly random number ortruly random instance, the characteristic of the object 194 may bepseudorandomly generated, such as by accessing a clock instance, bystepping through the digits of pi, or by any other method ofpseudorandomly generating a number or other instance; the publisher mayalso fulfill the role of specifying details of the CAPTCHA, includingthe characteristic of the object 194.) The characteristic of the object194 may be any of: the initial location, the initial orientation, theinitial speed, the initial direction of motion, the (initial) color, the(initial) size, the (initial) orientation, the (initial) shape, and the(initial) context of the object 194. Preferably, the irregularassignment of the characteristic of the object 194 differentiates theCAPTCHA from a previous CAPTCHA presented to the user or any other user.This preferably yields the benefit of generating a substantially uniqueCAPTCHA that automated software (e.g., a bot, an automated script,automated software), posing as a human, cannot solve by simply capturingan instance of the CAPTCHA and accessing the CAPTCHA solution by findingthe captured instance in a database of CAPTCHA instances and associatedCAPTCHA solutions. Specifically, CAPTCHAs thus generated may besubstantially unique, wherein (almost) every such CAPTCHA requires aunique solution to complete; this may force an automated script, posingas a human, to understand the CAPTCHA and fully comprehend the CAPTCHA,which is far more difficult to achieve than practices currentlyimplemented in the field of automated CAPTCHA solvers; such CAPTCHAS,therefore, may be more secure and accurate in isolating humans fromautomated software.

As shown in FIG. 2, the object 194 depicted within the graphicalinterface 193 preferably moves therein following initiation of theCAPTCHA, and the user is preferably required to manipulate or interactwith the object 194 to compete the CAPTCHA. As shown in FIGS. 5A and 6A,two different CAPTCHAs, including the same object 194 and additionalobject 195 within the same graphical interface 193 and the same prompt191, may require substantially different user interactions to completethe CAPTCHA despite the initial (T 0:00) similarities between the twoCAPTCHAs. Therefore, the step of pseudorandomly assigning acharacteristic to the object 193 of the CAPTCHA may have the benefit ofincreasing the difficulty for automated software to solve the CAPTCHA.

Other elements of the CAPTCHA may also be haphazard, randomly generated,pseudorandomly generated, or otherwise seemingly irregular. Such otherelements may be the prompt 191 (e.g., task, instruction, or challenge)of the CAPTCHA, the type of CAPTCHA (e.g., the game format), the shapeof the graphical interface 193, the type of user interaction or input,or any other aspect of the CAPTCHA. In a first example, the CAPTCHA ofFIG. 3F, including the graphical interface depicting four white circles,three hashed stars, an “A” bin, and a “B” bin may be pseudorandomlyassigned any of the following prompt 191: (1) drag the white circlesinto the “A” bin; (2) drag the white circles into the “B” bin; (3) dragthe hashed stars into the “A” bin; (4) drag the hashed stars into the“B” bin; (5) drag one hashed star and one white circle into the “A” bin;(6) drag one hashed star and one white circle into the “B” bin; (7) dragtwo hashed stars and one white circle into the “A” bin; (8) drag onehashed star and two white circles into the “B” bin; (8) drag one hashedstar into the “A” bin and one white circle into the “A” bin; etc.Furthermore, additional objects 195 (e.g., bins, circles, squares,stars, triangles, etc.) and/or colors may significantly increase thenumber of potential prompts associated with the CAPTCHA. In a secondexample, the CAPTCHA may be randomly selected from a set of genericCAPTCHA formats, such as from any of the formats depicted in FIGS.3A-3H, including Draw, Complete (Fill In), Build, Knock Down (Topple),Score, Drag, and Survey, or other formats including Move, Paint, Hammer,Shoot, Navigate, Destroy, Select, and Drop. In a third example, therequisite user input shifts between any of a cursor movement, a mouseclick, a keystroke, a voice command, a touch, a facial expression, agesture, or any other relevant user input or combination of user inputs.

The various aspects, elements, and characteristics of the CAPTCHA mayprovide a plethora of variables by which a substantially unique CAPTCHAmay be generated for the user, wherein the CAPTCHA is stillsubstantially easy for a human to complete but substantially difficultfor automated software to complete, such as with current methods ofautomated CAPTCHA solvers.

The CAPTCHA is preferably an object-based problem and provides a visualchallenge to the user that requires user interaction with the object194. The object-based problem preferably includes a prompt 191 (shown inFIG. 2) that instructs the user how to complete the CAPTCHA; the prompt191 may be text-based, but may also be audio- or graphic-based orprovided via any other suitable media. In some cases, the prompt 191 mayrely upon well-understood principles, and in some variations may beinherent in mechanics of the game, challenge, or survey defining theCAPTCHA. For example, the prompt 191 may instruct the user to navigate amaze while collecting prizes and avoiding enemies therein (shown in FIG.3E). This example may incorporate a wide variety of images of objectsthat a human would interpret as prizes (e.g., images of coins, icecream, toys) and as enemies (e.g., monsters, aliens); such contextualanalysis may be extremely difficult for automated bots to complete. Inan example of the CAPTCHA that is a survey, exemplified in FIG. 3H, theprompt 191 may ask the user to select a preferred Chevrolet Camaro froma list of Camaros, including a bittersweet red Camaro, a cherry redCamaro, a burgundy Camaro, a fire engine red Camaro, a rose Camaro, anda rusty Camaro; in this example, any selection of the rusty Camaro maybe deemed an incorrect answer, and any other selection may be added to adatabase of user preferences or survey results. However, the prompt 191may be of any other suitable type or form.

The user preferably provides a user input, through the graphicalinterface 193, to achieve the user solution to the CAPTCHA (the userinput is preferably tracked within the graphical interface 193). Theuser input is preferably one of a mouse interaction, a touchinteraction, a joystick interaction, an arrow interaction, a gesture, afacial expression, a voice command, and/or any other suitablenon-text-based form of navigation. Such forms of interaction arepreferably multidimensional in that they require a user interactionbeyond discrete inputs (e.g., transcribing text, single keystrokes). Forexample, a mouse or cursor input may provide a directional input alongtwo axes, a mouse state, and timing input (e.g., cursor speed), whereaskeystrokes provide only the state of a key and the timing of thekeystroke. The multidimensional aspect of the user input is preferablycaptured in Block 120 and analyzed in Block 150 to provide human and/orautomated software indicators distinct from the user solution. Theindicators preferably provide a second analytic by which to verify thatthe user is human. In a first example, the multidimensional aspectincludes a cursor path completed by the user in the process offulfilling the CAPTCHA; if the path is substantially geometric (e.g.,comprises straight and arcuate lines) the indicators suggest that theuser is inhuman because a typical human is unlikely to complete suchgeometric input motions. In a first variation of this first example, ifthe input path is substantially without noise, or the noise issubstantially greater than or less than input noise typical of a humanuser, then the indicators suggest that the user is inhuman; thisvariation and others may require Fourier analysis of the input pathand/or any other relevant mathematical manipulation thereof to isolate acharacteristic of the user input. In a second variation of the firstexample, if the input path includes substantially geometric inputchanges, such as from a linear path to an arcuate path or from asubstantially horizontal direction to a substantially vertical directionwithout typical lag, inaccuracy, or noise, the indicators suggest thatthe user is inhuman. In a second example, the multidimensional aspectincludes a timing element of the user input, wherein the indicatorssuggest that the user is inhuman if the input velocity is substantiallyfaster or slower than the input velocity of a typical human. In a firstvariation of the second example, if the user begins the task too soonafter (or too long after) initiation of the CAPTCHA, the indicatorssuggest that the user is inhuman. In a second variation of the secondexample in which the CAPTCHA includes the object 194 that is moving, theindicators suggest that the user is inhuman if the cursor input does notlag the motion of the object 194 within a range that is typical of ahuman user. However, the multidimensional aspect of the user input (userinteraction) may be of any other type and may be used in any other wayto determine human and/or automated software indicators.

The object 194 is preferably a graphical representation depicted withinthe user graphical interface 193 but may be any suitable representationof an element or tangible object 194; a plurality of objects may also bedepicted within the graphical interface 193. In one example, the object194 is a colored shape such as a blue circle or a yellow triangle. Inanother example, the object 194 includes a real-life image such as animage of an ocean or of a boat. The object 194 is preferably crucial tosolving the CAPTCHA, though the object 194 or any additional object(s)195 may be excessive and unnecessary to completing the CAPTCHA, thusserving to distract the user. As mentioned above, the object(s) mayleverage contextual or inherent properties of the associated image tocommunicate to a human a particular or inherent meaning; automatedsoftware may lack such contextual understanding, which may result in aCAPTCHA that is substantially easy for a human to solve but difficultfor automated software to complete.

As mentioned above, an option to change to an accessible version of theobject-based CAPTCHA may provide an alternative version thereof forblind or disabled users. This alternative challenge preferably includesan audio prompts to create an interactive audio-based CAPTCHA, but thechallenge may also implement vibratory or tactile feedback or any othermechanism to present the CAPTCHA (and the challenge thereof) to theuser.

The CAPTCHA prompt 191 may further be a dynamic prompt, the correctsolution(s) to the CATPCHA changing with the prompt 191. For any givenconfiguration of the challenge area 192 (e.g., a characteristic orsetting of the objects 194, 195) a plurality of generic prompts may beavailable for selection prior to initiation of the CAPTCHA. For example,in the challenge area 192 of FIG. 2, the following generic prompt typesmay be available: “Build a rectilinear bridge across Box A and Box B;”“Stack two squares and a star on Box C;” and “Drag four white circlesinto the C bin.” Also or alternatively, a plurality of CAPTCHA templateprompts, each with at least one variable, may be available for a givengeneric CAPTCHA format. For example, a template prompt includes “Drag NC1 O into the C2 bin,” wherein N: number, C1: color of the object, O:object, and C2: color of the bin. In this variation, the type of objectto drag (e.g., circle, square, star, octagon, etc.), the number of thoseobjects to drag, and/or the destination of the object(s) (e.g., where todrag an object) may define the variables of the prompt 191. Each prompt191 may have an associated type of challenge area(s), though the prompt191 may be included in any other number of prompt templates and theprompt 191 may include any other number of variables. The dynamic prompt191 preferably functions to introduce significant variability in theobjective of the CAPTCHA.

The graphical interface 193 of the CAPTCHA may also include additionaldynamic objects 195 (or other elements) within the challenge area 192;these additional dynamic objects 195 preferably provide additionalvariability amongst such CAPTCHAs and thus increase the number ofpossible unique CAPTCHAs with unique solutions. Preferably, theadditional dynamic objects 195 also move within the challenge area 192;motion of the additional dynamic objects 195, with the object 194, mayencourage more complex user interactions within the graphical interface193. In one variation, a physics engine controls interactions betweenthe object 194, the additional dynamic objects 195, the challenge area192 (e.g., the perimeter of the graphical interface 193), and/or theuser (e.g., a cursor); the physics engine may therefore function torequire the user to understand complex inter-object interactions.Furthermore, may change over time within the CAPTCHA: the representationof the object 194 and the additional dynamic objects 195; the number ofinstances of a type, shape, color, context, speed, and/or direction ofmotion of the object 194 and/or additional dynamic object 195; a gameplay mechanic; an interaction parameters such as friction or gravity; orany other suitable aspect or characteristic of the CAPTCHA.

The challenge area 192 depicted within the graphical interface 193 mayalso be dynamic, wherein the challenge varies in size, shape,orientation, and/or position within the graphical interface 193 from oneCAPTCHA to the next, thus functioning to further increase variabilityamongst such CAPTCHAs.

The object 194, additional dynamic objects 195, other objects orelements depicted within the graphical interface 193, the challenge area192, and/or any other aspect, characteristic, or elements of the CAPTCHAmay also be themed. A theme for the CAPTCHA may provide context for theCAPTCHA and/or imply the prompt 191 for the CAPTCHA. The theme may alsoprovide an avenue for the publisher of the CAPTCHA, an externaladvertiser, or any other third party to customize the CAPTCHA to deliveran advertisement or other message to the user. Such third-party theming(or branding) of the CAPTCHA may provide a vehicle by which CAPTCHAs maybe customized, thus increasing the diversity and uniqueness of CAPTCHAs,while furnishing an engaging medium for users to view advertisements.Because the user may be actively engaged in completing the CAPTCHA thatincludes an advertisement, the advertisement within the CAPTCHA may havea greater impact on the user than current web- and mobileapplication-based advertising strategies. A software development kit(SDK) for the CAPTCHA and related service are preferably provided to thepublisher, external advertiser, or other third party for use in: addingassets (e.g., marketing material) to existing CAPTCHAs; adding assets togeneric CAPTCHA formats; customizing CAPTCHAs; creating unique CAPTCHAsand/or generic CAPTCHA formats; modifying and/or defining correctsolutions to CAPTCHAs; adjusting the threshold likeness score; or forany other suitable purpose. CAPTCHAs and/or changes to existing CAPTCHAsmay be automatically tested and/or integrated within the serverconfigured to provide the CAPTCHA. The SDK is preferably provided via adashboard accessible by the publisher (or representative thereof) or viaa web-based application or program, though the SDK may be provided inany other form.

Block S110 of the preferred embodiment, including receiving the usersolution to the CAPTCHA, functions to capture the result of the CAPTCHA,provided by the user, for subsequent comparison to a correct solution ofthe CAPTCHA. Block S160, including calculating the human likeness score,preferably accounts for the user solution to the CAPTCHA, since analysisof the user interaction pattern alone may not adequately inform thehuman likeness score. The CAPTCHA is preferably substantially easy for ahuman user to complete and substantially difficult for automatedsoftware to complete, preferably due to the context of objects depictedwithin the CAPTCHA, variability within the CAPTCHA, object-specificprompts, and/or other characteristics of the CAPTCHA described above.The user solution, when compared to a correct solution for the CAPTCHAin Block S140, may therefore present a significant indication of thehumanness of the user. The user solution is preferably captured by thepublisher presenting the CAPTCHA and then transmitted to the server forsubsequent analysis and manipulation in Blocks S140 and S160, as shownin FIG. 4. However, the user solution may be captured by any otherassociated entity, such as the website or application hosting theCAPTCHA or directly by the server; the user solution may also betransmitted to any relevant entity for such analysis and manipulation.

The user solution preferably includes the state of the CAPTCHA uponcompletion thereof by the user. Cessation of the CAPTCHA may beautomatic, wherein the CAPTCHA ceases following a solution provided bythe user or expiration of specified game time; alternatively, cessationof the CAPTCHA may be manual, wherein the CAPTCHA ceases only followinga specific input by the user, such as a user selection of a “Submit”button or a “Finished” button. The user solution is also preferablydistinct from the user interaction or user interaction pattern.Specifically, the user interaction is preferably any portion of a userinteraction within the CAPTCHA, graphical interface, or challenge areaprior to completion of the CAPTCHA. The user solution is preferably thestate of the CAPTCHA upon completion thereof, but may also includeadditional states or instances of the CAPTCHA prior to completionthereof. In a first example shown in FIGS. 5A, 5B, and 5C, the prompt ofthe CAPTCHA is “Drag four white circles into the bin with the orange C;”at twelve seconds (T 0:12), the user drags a first white circle into theorange bin; at fourteen and eighteen seconds (T 0:14, T 0:18), the userdrags a second and third white circle into the orange bin; and attwenty-one seconds, the user drags a fourth white circle into the orangebin. In this first example, the user solution is preferably four whitecircles dragged into the orange bin, despite the fact that the whitecircles were dragged into the orange bin at separate times. In a secondexample shown in FIGS. 7A, 7B, 7C, and 7D, the prompt of the CAPTCHA is“Build a tower with the white squares and knock it down with the whitecircle;” the user builds a tower with the white squares by nineteensecond (T 0:19); and the user drags the white circle over the tower toknock the tower down at twenty-three and twenty-seven seconds (T 0:23, T0:27). In this second example, the user solution preferably includes aninstance of the constructed tower and at least two instances of thecircle knocking down the tower. In a third example implementing aPac-Man-like game, as shown in FIG. 3E, the user solution preferablyincludes: the final score achieved by the user; each instance in whichthe user captures a dot or power pellet; and each instance in which aghost meets the user. However, the user solution may be of any othertype and include any other information relevant to the CAPTCHA.

Block S110 of the preferred embodiment, including receiving the userinteraction pattern descriptive of an interaction undertaken by theuser, through the graphical interface, to achieve the user solution,functions to capture an input of the user for subsequent comparisonagainst interactions of other users indicative of human and/or automatedsoftware characteristics of the user. Block S160, including calculatingthe human likeness score, preferably accounts for the user interactionpattern, since analysis of the user solution alone may not adequatelyinform the human likeness score. The CAPTCHA preferably requires a userinteraction that is distinct from the user solution, such as a cursormovement, a mouse click, a keystroke, a voice command, a touch, a facialexpression, a gesture, or any other relevant user input that is not aninstance specific to a solution of the CAPTCHA. For example, a purelytext-based CAPTCHA that requires the user to type in the words depictedin a distorted image, wherein the user interaction is solelykeystroke-based, may not provide a vehicle by which to capture the userinteraction (although, in some variations, the timing of a userkeystroke may define the user interaction of the CAPTCHA of thepreferred embodiment). However, a CAPTCHA requiring a cursor or touchinput (or other multidimensional input), such as the CAPTCHA shown inFIGS. 3A-3H, may provide an appropriate vehicle by which to capture theuser interaction. In a first example, the user interaction is a portionof the cursor path shown in FIG. 1. In a second example, an image ofsomething typically considered funny is first presented, within thegraphical interface of the CAPTCHA, to the user; an image of somethingthat is sad is subsequently presented; the user interaction is a facialexpression of the user (e.g., captured by a camera incorporated into thedigital device), wherein a user solution in line with a correct solutionincludes a first facial expression that is a smile and a second facialexpression that is a frown or wince substantially soon after the firstand the second images are released to the user. However, the userinteraction may be of any other form and captured in any other way.

The user interaction is preferably captured within the graphicalinterface of the CAPTCHA, such as in the variation in which the userinteraction is a touch or cursor motion within the graphical interfaceand provided via a mouse, touchpad, touch screen, trackpad, joystick,game controller, or other user input device. In this variation, the userinteraction may be captured by the publisher presenting the CAPTCHA, bythe website or application hosting the CAPTCHA, the server generatingthe CAPTCHA and/or calculating the human likeness score, or any otherassociated entity. Alternatively, a peripheral device in communicationwith the digital device, such as a camera (integral with or plugged intothe digital device), a digital wristband (e.g., the Jawbone UP), a cellphone with an integral accelerometer or gyroscope, a gaming console, orany other suitable peripheral device, may be accessed by the publisher,website, application, server, and/or other associated entity to trackand capture the user interaction.

The user interaction is preferably captured by the publisher presentingthe CAPTCHA and then transmitted to the server for subsequent analysisand manipulation in Blocks S150 and S160, as shown in FIG. 4. However,the user interaction may be captured by any other associated entity,such as the website or application hosting the CAPTCHA or directly bythe server; the user interaction may also be transmitted to any relevantentity for such analysis and manipulation.

The method S100 may further comprise the block of receiving user datathat is distinct from the CAPTCHA S130. Block S160, includingcalculating the human likeness score, preferably accounts for the usersolution and the user interaction pattern in calculating the humanlikeness score; however, Block S160 may also incorporate user data tofurther inform the human likeness score. In a first variation in whichthe user data includes a CAPTCHA (or indication thereof) previouslypresented to the user, the data may indicate how many CAPTCHAs the userhas attempted in a given period of time. In a first example, more that100 attempted CAPTCHAs within a twenty-four-hour period indicates thatthe user is automated software as this is uncharacteristic of a typicalhuman user. In a second example, a previous CAPTCHA that was failed bythe user suggests that the user may be inhuman, and the subsequentCAPTCHA selected for the user is substantially more difficult forautomated software to complete that the prior CAPTCHA. In a secondvariation, the user data includes an Internet Protocol (IP) address ofthe user. In a first example of the second variation, if the user IPaddress is associated with a location in which humans are historicallypaid for solving CAPTCHAs (e.g., India and China), the user data is usedto select a more difficult CAPTCHA or to reduce the human likeness scoreof the user, as shown in FIGS. 8A and 8B. (In this example, the humanlikeness score may be considered ‘an appropriate user score’ rather thana human likeness score since, although a paid human solver is stillhuman, such paid human solvers (e.g., human spammers) may not beconsidered appropriate users and a service employing such CAPTCHAs maydesire to restrict access to such paid human solvers.) In a thirdvariation, the user data is a cookie associated with the user. In afirst example of the third variation, as shown in FIG. 1, a plurality ofuser cookies are used to determine if the user has accessed a website ina manner typical of a human, such as by searching for and accessing thewebsite through Google. In a second example, timestamps may be gleanedfrom user cookies to determine if usage is characteristic of a human(e.g., the user sleeps and is not at a computer for more thantwenty-four hours at a time). In a third example, user cookies indicatethat the user visits other websites that do not require user completionof CAPTCHAs, which suggests that the user is not automated software. Theuser IP address and/or user cookie may also be used to link the user topast CAPTCHA attempts, to link the user to a previous human likenessscore, and/or to ascertain whether the user was previously determined tobe human. In a fourth variation, a social networking account (e.g.,Facebook account) of the user may be accessed and data siphonedtherefrom. In a first example, the age and friends of the user arecompared to a list of favorite music and books of the user to determineif the interests of the user match the age or demographic of the user,wherein a mismatch suggests that the user is an automated script (andthat the social network account is falsified). In a second example, thedemographic of the user is siphoned from the account of the user todetermine a demographic of the user, such as age, race, gender,nationality, education level, existing disabilities or handicaps, fieldof employment, etc., which may be subsequently used in Block S150 in thecomparison of the user interaction pattern to interaction patterns ofprevious users. However, any other user data may be collected and usedin any other way.

The publisher, the host website or application, or the server maycapture the user data and the user data may be transmitted between anyrelevant parties for subsequent analysis in Block S155•

Block S140 of the preferred embodiment, including determining theaccuracy of the user solution, functions to determine if the usersolution is correct and/or falls within a range of acceptable (e.g.,correct) solutions to the CAPTCHA. As mentioned in a preceding section,Block S160, including calculating the human likeness score, preferablyaccounts for the user solution to the CAPTCHA, since analysis of theuser interaction pattern alone may not adequately inform the humanlikeness score. Because the CAPTCHA is preferably substantially easy fora human to complete and substantially difficult for automated softwareto complete, the accuracy of the user solution is preferably ascertainedin Block S140. In a first variation in which the CAPTCHA has a singlecorrect solution, the user solution may be compared thereto. Forexample, for a CAPTCHA with the prompt “Click ‘Finished’ after draggingone black circle into the yellow bin,” the user solution is determinedto be correct only if the user drags a single black circle into theblack bin prior to clicking “Finished,” and the user solution isdetermined to be incorrect if the user drags two black circles into theyellow bin or drags one yellow circle into the black bin. In a secondvariation in which the CAPTCHA has a range of correct solutions, BlockS140 preferably determines if the user solution falls within the boundsof correct solutions. In a first example of a CAPTCHA with the prompt“Drag two black circles into the yellow bin,” the user solution isdetermined to be correct regardless of which black circle is draggedinto the yellow bin first. In a second example of a CAPTCHA with theprompt “Build a tower from the squares and then knock it down with thewhite circle,” if the user completes the prompt, the user solution isdetermined to be correct regardless of where the tower is constructedwithin the graphical interface, the order in which the squares arearranged to construct the tower, the color of the squares, or whichsquare is hit first with the circle when the user topples the tower.However, in this example, if the user employs a yellow circle to topplethe tower, or the user adds a triangle to the tower, the user solutionis preferably deemed outside the bounds of a correct solution andtherefore improper. However, the user solution may be analyzed in anyother way.

Block S150 of the preferred embodiment, including comparing the userinteraction pattern against an interaction model generated frominteraction patterns of previous users, functions to isolatecharacteristics of the user interaction that are indicative of a humanuser and/or an automated user. The user interaction is preferably any ofthe aforementioned user interactions, such as a cursor or touch motion,and the user interaction pattern is preferably a portion of the userinteraction. The user interaction pattern may be a snippet of the userinteraction, such as a particular section of a cursor path providedwithin the graphical interface (e.g., a portion of the cursor path shownin FIG. 1) or the geometry of the input path (e.g., the angle of adirection change or the linearity of a portion of the input), as shownin FIGS. 10A-C; alternatively, the user interaction pattern may be acharacteristic of a portion or the entirety of the input path, such asaverage noise in the input path, the length of the input path, theaverage speed of the input, or where along the input path a mouse clickis generated. However, the user interaction pattern may be of any othercharacteristic of the user interaction.

In a first variation, the user interaction is a path-type input (e.g., acursor or touch motion) and the user interaction pattern is noise in aportion of the input path; the noise may be oscillations or deviationsfrom a smooth input path, and Block S150 may include comparing the inputpath noise to input noise typical of a human or comparing thesignal-to-noise ratio of the input path to a signal-to-noise ratiotypical of a human, as shown in FIGS. 9A-9E. In this example, Block S150may therefore calculate a human likeness score of the user based on adegree of similarity between the signal-to-noise ratio—characteristic ofthe user input—and the model signal-to-noise ratio pattern defined inthe interaction model. In a second variation, the user interaction is apath-type input provided through the graphical interface and the userinteraction pattern is a direction change in a portion of the inputpath; Block S150 may include comparing the direction change of the inputpath to a direction change typical of a human interaction within thegraphical interface. In a third variation, the user interaction is apath-type input and the user interaction pattern is an input velocity ofa portion of the input path; Block S150 includes comparing the inputvelocity to an input velocity typical of a human interaction within thegraphical interface. In a fourth variation, the user interaction patternis a characteristic of a response to a moving object within thegraphical interface; Block S150 includes comparing the user responsewith a characteristic of a response typical of a human interactionwithin the graphical interface. In this fourth variation, thecharacteristic of the response may be any of: a lag in direction changeof an input relative to a direction change of the moving object (e.g.,moving a Pac-Man-type figure within the graphical interface following achange of direction of a moving ghost therein); an input path leading upto selection of the moving object (e.g., the user attempting to catch amoving object within the graphical interface); an input path followingrelease of the moving object (e.g., an input path including dragging anobject into a bin); input timing following a change in distance betweenthe object and a second object depicted within the graphical interface(e.g., a change of input following collision of two objects within thegraphical interface); or any other relevant characteristic of the userinteraction. In a fifth example in which the user interaction is a voicecommand, the user interaction pattern is voice inflection; theinflection provided by the user is compared against typical human voiceinflections. In a sixth example, the user interaction is a facialexpression and the user interaction pattern is the transition from oneexpression to another; the transition is compared against typicaltransitions by known humans, such as the stretching and wrinkling ofskin around the eyes and cheeks (and the timing thereof) as the userbegins to smile. However any other user interaction pattern of any otheruser interaction may be compared against any interaction model (e.g., atypical characteristic or behavior of a known human or of knownautomated software).

The interaction model preferably comprises characteristics and/orbehaviors of users of known types (e.g., humans and/or automatedscripts). The interaction model preferably includes data generated by atleast one user that was/is a known human, such as input noise, inputdirection change, input speed or velocity, a response to a movingobject, a voice inflection, a facial expression, or any other relevantcharacteristic of a human, and the interaction preferably include datagenerated by a plurality of known humans, such as ten, 100, 1000, or10,000 known humans. However, the interaction model may also oralternatively include data generated by at least one user that was/is aknown “bot” (automated software). The data is preferably stored in adatabase accessible by the server (or other entity completing BlockS160), and the interaction model preferably comprises at least oneisolated characteristic that is typical of a human user. However, theinteraction model may define any number of typical humancharacteristics, and all or a (pseudorandomly selected) portion of thedefined characteristics in the interaction model may be compared againstthe user interaction pattern in Block S150. The interaction model ispreferably generated from user interactions of previous users to whomsimilar CAPTCHAs have been presented, but may alternatively be from userinteractions of users accessing websites or applications not presentingCAPTCHAs to the users. In one example, a high-traffic website, such asGoogle.com, captures cursor movements on the Google homepage; thesecursor motions are then be used, at least in part, to define theinteraction model, even though CAPTCHAs are not typically presented onthe Google homepage. Alternatively, the interaction model may besynthetic. For example, the interaction model may consist solely ofcomputer code that defines a user interaction characteristic expected ofhuman or automated users.

The interaction model may be static, wherein, once the typical humancharacteristic(s) is defined therein, the interaction model does notchange. However, the interaction model may alternatively be dynamic,wherein subsequent user interactions from subsequent CAPTCHAs presentedto a variety of users may be added to the interaction model. This mayhave the benefit of providing a more complete interaction model thataccounts for human users of a wider variety of demographics. Forexample, teenage users may provide significantly faster input speeds andprovide a solution to CAPTCHAs significantly faster than sexagenarians.A demographic of the user (such as determined in Block S130) may thusisolate a portion of the interaction model such that the userinteraction is compared against user interactions of previous users in ademographic similar to that of the user, and this may have the benefitof improving the accuracy of the comparison of Block S150, thecalculated human likeness score of Block S160, and/or the verificationthat the user is human (Block S170); this in depicted in FIGS. 8A and8B. However, the user interaction and/or user interaction pattern ispreferably added to the dynamic interaction model only if the servicemanaging the interaction model (e.g., the server) is substantiallyconfident that the user is human. For example, the user interactionpattern may only be added to the interaction model if the human likenessscore is (substantially) greater than a threshold likeness score,wherein a human likeness score greater than the threshold likeness scoreis indicative of substantial confidence that the user is human.

The interaction model is preferably generated, maintained, and/orupdated by the server. However, any other entity may administer theinteraction model, such as the publisher, and the interaction model maybe generated, manipulated, maintained, and updated in any other way.

Block S160 of the preferred embodiment, including calculating the humanlikeness score based upon the determination of Block S140 and thecomparison of Block S150, functions to generate a value associated withconfidence that the user is human (or automated software). The humanlikeness score is preferably a quantitative value included in acontinuum of human likeness scores. In a first example, the continuum ofhuman likeness scores includes 0 and all integers between 1 and 10,wherein a human likeness score of 9 reveals a relatively low confidencethat the user is human and a human likeness score of 2 reveals arelatively high confidence that the user is human. In a second example,the human likeness score is a percentage, from 0% to 100%, wherein ahuman likeness score of 15.62% reveals a relatively low confidence thatthe user is human and a human likeness score of 91.17% reveals arelatively high confidence that the user is human. However, thecontinuum of human likeness scores may contain any other range and be ofany other quantitative type. Furthermore, the continuum of humanlikeness scores may be qualitative. For example, the human likenessscore may be selected from: “Definitely Not Human,” “Highly Unlikely ToBe Human,” “Probably Not Human,” “May Not Be Human,” “Probably ACyborg,” “May Be Human,” “Probably Human,” “Highly Likely To Be Human,”“Definitely A Human,” and any other relevant qualitative descriptor.

As shown in FIGS. 8A and 8B, Block S160 may utilize a decision tree tocalculate the human likeness score. Various disparate elements, such asany of the user solution, user interaction patterns including noise andinput geometries, and user data including an IP address, may beaccounted for within the decision tree to ultimately select anappropriate human likeness score. The decision tree may further aid inisolation of the user into a particular user group, such as automatedsoftware, human spammer, and human, as shown in FIGS. 8A and 8B.Subgroups of these groups may also be implemented, such as demographicsubgroups for humans (e.g., age, race, gender, education level) orlocation subgroups for human spammers (e.g., United States, India,China). The interaction model preferably includes substantial data foreach group and/or subgroup such that a user, once isolated into a group,may be compared against similar users in Blocks S140, S150, and/or S155.Human likeness scores may be adversely affected for users withcharacteristics, solutions, and/or data outside what is typical oroutside a predefined bound or cutoff for a particular group or subgroupinto which the users have been placed; this may yield the benefit ofimproving the accuracy of the human likeness scores and thedetermination of the category of user (e.g., human, spammer, automatedscript). These groups and/or subgroups may also be dynamic, whereingroups and/or subgroups are added or deleted as additional data is madeavailable through additional completions of CAPTCHAs by users.

Alternatively, Block S160 may utilize a weighted average to calculatethe human likeness score for the user. Each element of the usercompletion of the CAPTCHA, including the user solution, the userinteraction(s), and/or the user data may be separately compared againstthe correct CAPTCHA solution, the interaction model(s), and/or typicaluser data; the separate comparisons may then be weighted (e.g., 50% forthe user solution, 30% for the user interaction, and 20% for the userdata; or all weighted equally) and combined into a single human likenessscore. In one variation: Block S140 further includes generating a firstconfidence group based upon the user solution; Block S150 furtherincludes generating a second confidence group based upon the userinteraction pattern; and Block S155 further includes generating a thirdconfidence group based upon the user data. In this variation, Block S160further includes determining the reliability of the first, second,and/or third confidence groups. In one example of determining thereliability of a confidence group, though the user provides an incorrectsolution to the CAPTCHA, the user is determined to be a 75-year-old maleand the confidence group based upon the user solution is determined tobe substantially less reliable in suggesting that the user is human thaneither of the user interaction or the user data. In a second example ofdetermining the reliability of a confidence group, user data suggeststhat the user has attempted 107 CAPTCHAs in the previous eight hours,and this data is determined to be substantially more reliable insuggesting that the user is automated software (or a human spammer) thanthe user solution or the user interaction. Block S160 may thus includecompiling the first, second, and/or third confidence groups, based uponthe determined reliability thereof, to generate the human likenessscore.

Furthermore, Block S160 may utilize artificial neural networks, supportvector machines, inductive logic programming, or other methods enablingmachine learning. However, the human likeness score may be generated inany other way and with any other data or combination of data.Furthermore, an automated software likeness score may be calculated inBlock S160 in addition to or in place of the human likeness score; theautomated software likeness score may be calculated in any suitable way,such as by the decision tree or weighed average methods described above.

The method S100 may further comprise Block S170, including comparing thehuman likeness score to a threshold likeness score. This comparisonpreferably indicates that the user is either a human or an automatedscript, but may also indicate that the user is a human spammer or thatthe user belongs to any other group to which access should be restrictedor permitted. The threshold likeness score may be fixed, such as at 65%,wherein a human likeness score greater than or equal to 65% indicatesthat the user is human and a human likeness score less than 65%indicates that the user is either inhuman, a human spammer, or withinanother group with restricted or limited access. However, the thresholdlikeness score may be variable. In a first example, the thresholdlikeness score is modified on a daily basis in order to meet a quota ofusers determined to be human (and thus granted access). In a secondexample, the publisher of the CATCHA adjusts the threshold likenessscore to meet the needs of the publisher or host website or application.In a variation of this second example in which the publisher is agovernment agency, the publisher may set the threshold likeness score,for a government website, particularly high at 90% in order tosubstantially prevent spammers and automated scripts from accessing thesite; in a variation of this second example in which the publisher is anonline forum with a limited number of users, the publisher may set thethreshold likeness score particularly low at 45% in order maintain ahigher level of access to the site for potential new users. Suchadjustments are preferably made by the publisher or host website orapplication through the aforementioned dashboard; the dashboard ispreferably accessible through a web browser or mobile application. Thepublisher, etc., may also user the dashboard to submit an asset,marketing materials, or advertising data, or to generate generic CAPTCHAformats or customize existing CAPTCHA formats. Block S170 may thereforeinclude setting, for the user, a custom range of human likeness scorescorresponding to humans based on web traffic history of user, and BlockS170 may thus associate the user (e.g., the user's identification data)with a human determination based on the user's human likeness score thatfalls within the custom range of human likeness scores corresponding tohumans. Block S170 may implement similar methods and techniques to set,for the user, a custom range of human likeness scores corresponding toautomated software, professional human CAPTCHA solvers, and professionalweb traffickers based on web traffic history available for the user, andBlock S170 may thus associate the user with a determination of automatedsoftware, professional human CAPTCHA solver, or professional webtrafficker based on the user's human likeness score that falls withinthe custom range of human likeness scores corresponding thereto.However, the threshold likeness score may be adjusted, modified, oraccessed in any other way.

The result of the comparison of the human likeness score to thethreshold likeness score is preferably presented to the publisher orhost website or application such that the publisher or host mayimmediately allow or restrict access for the user. In one variation, theserver transmits the verification that the user is one of a human,automated script, or human spammer (of Block S170) to the publisher orhost. In an alternative variation, the server transmits solely the humanlikeness score to the publisher or host; in this variation, therecipient of the human likeness score may analyze or otherwisemanipulate the score, such as by comparing the human likeness score to athreshold likeness score managed directly by the recipient.

The method S100 may further comprise Block S180, including adding theuser solution to a catalog of user preferences. Block S180 is preferablycompleted for a CAPTCHA that defines a survey, wherein the user solutionto the CAPTCHA is indicative of a user preference, and the userpreference is preferably only added to the catalog if the human likenessscore of the user is above a given value and/or the user is determinedto be human. In the example above in which the CAPTCHA requests a userpreference for a shade of red of a Chevrolet Camaro, the user solution(that is not the rusty Camaro) may be added to the catalog and thecatalog subsequently used by General Motors in the selection of thestandard shade of red for a future Chevrolet Camaro line. However, theCAPTCHA that is a survey may be of any other form and test any otheruser preference.

The catalog of user preferences is preferably provided to the publisherand/or the host website or application, but may be made available to anyother relevant third-party entity. In the example above: the server maysimply serve to complete Blocks S100 through S160 of the method S100;the host may be a website paid by the publisher to display the CAPTCHAsurveys; the publisher may be a marketing agency tasked with assemblingsurvey CAPTCHAs for General Motors; General Motors may be a third partythat pays for the results of the survey, wherein General Motors receivesthe results of the survey through the publisher. However, any partiesassociated with the method S100 may fulfill any other role and share anyother information or survey result with any other party.

In the variation in which the CAPTCHA is a survey, the generic form ofthe CAPTCHA is preferably generated by the publisher (or arepresentative thereof). The publisher preferably accesses a dashboardprovided by the server and generates the generic survey CAPTCHA therein,such as by providing assets and materials available to the publisher.Alternatively, the server (or a representative thereof) may receiveassets from the publisher and generate the generic survey CAPTCHA at therequest of the publisher. However, any other entity may generate and/oradjust the survey-type CAPTCHA. Furthermore, an asset provided by thepublisher or other entity may simply be incorporated into the CAPTCHA asan advertisement, wherein the advertisement is distinct from any surveyaspect of the CAPTCHA. The CAPTCHA selected for the user may be basedupon the advertisement depicted therein, wherein the advertisement istailored to user, such as by noting a cookie of the user, a past websitevisited by the user, an interest of the user siphoned from a socialnetwork or other account, or a demographic of the user; for example, theCAPTCHA of FIG. 3H may be matched to the user of FIG. 1.

The method S100 may further comprise Block Sf90, including generatingthe CAPTCHA. The CAPTCHA is preferably generated by the server uponrequest for a CAPTCHA from the publisher and/or the host of the websiteor application. However, the publisher or host may also generate theCAPTCHA. The CAPTCHA is preferably selected from a set of availablegeneric CAPTCHA formats, such as those shown in FIGS. 3A-3H. The set ofavailable CAPTCHA formats may be specific to a particular publisher orhost, and the selection thereof may be suggested or requested directlyby the publisher or host. Once the format of the CAPTCHA is selected,details thereof are preferably subsequently assigned. Specifically, asdescribed above, a characteristic of the object depicted within thegraphical interface of the CAPTCHA is preferably pseudorandomlyassigned, such as any of an initial location, an initial orientation, aninitial speed, and an initial direction of motion to the object. Oncethe CAPTCHA is selected and/or the relevant details thereof determined,the entirety of the CAPTCHA may be transmitted to the publisher and/orhost for subsequent presentation to the user. However, generic CAPTCHAformats may be stored by the publisher and/or host such that only thedetails of the variables of the CAPTCHA must be transmitted thereto;this may yield the benefit of decreasing the time between when the userattempts to access a site or service and when the CAPTCHA is presentedto the user. However, the CAPTCHA and the details thereof may begenerated, selected, assigned, and/or transmitted in any other way.

As shown in FIG. 12, one variation of the method includes: receiving arequest from a publisher for a human likeness score of a user accessinga webpage through a web browser executing on a computing device; basedon the request, collecting identification data of the user; collecting acursor motion entered by the user into the web browser; extracting anoise component from the cursor motion; identifying a motion geometry inthe cursor motion; accessing a noise model defining input noisecharacteristics of cursor inputs previously entered into graphical userinterfaces by known humans; accessing a motion model characterizingcursor motion geometries previously entered into graphical userinterfaces by known humans; calculating a human likeness score of theuser based on a comparison of the noise component to the noise model andbased on a comparison of the motion geometry to the motion model, thehuman likeness score lying within a continuum of human likeness scores;and associating the identification data of the user with a humandetermination based on the human likeness score falling within a rangeof human likeness scores corresponding to humans.

A similar variation of the method includes: receiving a request from apublisher for a human likeness score of users accessing a webpageaffiliated with the publisher; in response access of the webpage by auser through a web browser executing on a computing device, collecting acursor motion entered by the user into the web browser; extracting anoise component from the cursor motion; accessing a noise model defininginput noise characteristics of cursor inputs previously entered intographical user interfaces by known humans; calculating a human likenessscore of the user based on a comparison of the noise component to thenoise model, the human likeness score lying within a continuum of humanlikeness scores; and transmitting a human determination of the user tothe publisher based on the human likeness score of the user fallingwithin a range of human likeness scores corresponding to humans.

Generally, as described above, the foregoing variations of the methodmay be executed within a webpage—accessed by a user through a webbrowser—and outside of a graphical interface defining a traditionalCAPTCHA. For example, Blocks of the method may be executed on a remoteserver in cooperation with a webpage publisher to track interactions(e.g., cursor inputs) entered by a user over a webpage within a webbrowser and to extrapolate a human likeness score for the user from theinteractions, such as exclusive of a user solution to an implicit orexplicit CAPTCHA-related prompt or instruction provided through thegraphical interface. The method may therefore be executed to distinguishhuman users and automated users based on user interaction data collected“in the background” as a user browses a webpage (or multiple webpages).However, the human users and automated users can be distinguished in anyother suitable manner, based on any other suitable information.

In the foregoing variations, a remote server, an application server, orother computer or computer network may execute the method describedabove for distinguishing humans users from automated users (i.e.,automated software) in response to receiving a request from a webpublisher for monitoring the particular user as or once the user hasnavigated to a particular webpage. The method may therefore selectivelyapply the foregoing procedure for distinguishing humans users fromautomated users to a subset of traffickers to a particular webpage or toa particular website. Alternatively, the remote server (or computer orother computer network) may be set to execute the procedure describedherein for each user or for each new user who accesses the particularwebpage. Therefore, in this variation, once a user navigates to and/oropens a particular webpage, the remote server (or computer or othercomputer network) may initiate the method by collecting cursor and/orother inputs entered into the his web browser over the particularwebpage. For example, the remote server may record a cursor motionentered by the user through the web browser in response to access of thewebpage by the computing device through the (user's) web browser. Asdescribed above, the method may collect and store (e.g., remotely in aremote database), a cursor path, mouse clicks, keystroke, a gesture,and/or other inputs entered by the user into a computing device whileviewing the webpage.

Upon receipt of a request to apply the method to a particular usernavigating to a particular webpage or in response to navigation by theparticular user to a website contracted for application of the method,the remote server (or other computer or computer network) may implementmethods and techniques described above to collect identificationinformation of the user, such as the user's Internet Protocol (“IP”)address. The remote server may then apply methods and techniquesdescribed above to transform cursor inputs, keystrokes, mouse clicks,and/or other inputs supplied by the user through the web browser into ahuman likeness score and to then transform the human likeness score intoa determination that the user is either a human user or automatedsoftware (or a human user paid to navigate through websites).

The remote server may then execute Blocks of the method to store thehuman likeness score calculated for the user with the user'sidentification information (e.g., IP address), such as in a remotedatabase with human likeness scores and identification information ofall other users monitored according to the method, of all other userwith the same or similar human likeness scores, of all other usersmonitored according to the method within a particular period of time(e.g., three months), of all other users monitoring within a particularland area or region (e.g., the western United States), of all otherusers monitored on behalf of the publisher of a group of publishers,and/or of all other users trafficking the particular webpage or website,etc. The remote server may also store the human (or automated software)determination calculated for the user—with a user identifier and/orhuman likeness score—in the database; the remote server may similarlygroup the user identifier and human likeness score within other usersassociated with the same human (or automated software) determination.The user identifier can be a user IP address or be any other suitableidentifier. The remote server (or other computer or computer network)may thus implement Blocks of the method to build a “white list” of IPaddresses (or other identification information) of users who havepreviously been determined to be human; the remote server may similarlyimplement Blocks of the method to build a “blacklist” of IP addresses(or other identification information) of users who have previously beendetermined to be automated software or paid Internet traffickers.

The method can additionally or alternatively include categorizing userswithin a third party's list of user identifiers based on the generatedlist, which can function to identify human users within the third partylist, remove non-human users from the third party list, or otherwiseleverage the information within the third party list. Categorizing userswithin a third party's list of user identifiers can include matching(e.g., within a margin of error, exactly, etc.), synchronizing, orotherwise identifying unique user identifiers shared between thegenerated list(s) and the third party user identifier list(s). In onevariation, the human likeness score from the generated list can beassigned to the corresponding user identifier within the third partyuser identifier list. In a second variation, the user identifiers sharedbetween the white list and the third party user identifier list can bepositively identified as human users. In a third variation, useridentifiers shared between the black list and the third party useridentifier list can be positively identified as automated software orInternet traffickers. However, the user identifiers within the thirdparty list can be otherwise categorized.

The third party user identifier list can include a list of emailaddresses, IP addresses, MAC addresses, or any other suitable type ofidentifier. The identifiers within the third party list can be the sametype as that of the generated list, or be different. In the latterinstance, a reference list can be used to translate the identifierwithin the generated list into the identifier within the third partylist. For example, a reference list having emails associated with IPaddresses can be used to translate IP addresses (used by the generatedlist) into email addresses (used by the third party list), such that thehuman likeness score or other information within the generated list canbe assigned based on matching email addresses, However, the usersidentified within the third party list can be otherwise categorized.

Thus, in the foregoing implementation, when a particular user returns tothe same webpage at a later time, the remote server may access the whitelist, identify the user on the white list based on the user's current IPaddress that matches an IP address stored in the white list, and pass ahuman determination (or other confirmation to provide access to theuser) back to the publisher substantially immediately (e.g., in real- ornear-real time) upon navigation by the user to the webpage (or website)and without necessitating capture and processing of the user's cursorinputs, keystrokes, mouse clicks, etc. to generate a new human likenessscore for the user. Similarly, the remote server (or other computer orcomputer network) may retrieve the user's human likeness score from thedatabase in response to receipt of a request from a second publisher forthe human likeness score associated with the Internet Protocol addressof the user. The remote server may therefore: collect a first set ofinteractions entered by the user into a web browser while viewing onewebpage or website; generate a human likeness score and/or a human (orautomated software) determination from the human likeness score based onthe first set of interactions; store the human likeness score and/or thehuman determination of the user with the user's IP address; and recallthe user's human likeness score and/or human determination from thedatabase or other memory when the user visits a second webpage orwebsite, such as in response to a request from a second publisher for ahuman likeness score and/or a human determination of the user when theuser navigates to the second webpage or to the second website affiliatedwith the second publisher. The remote server may further pass the user'shuman likeness score and/or human determination with the user's IPaddress (or other identification information) to the second publisher asdescribed above.

Furthermore, when the user navigates to the same or other webpage at alater time, the remote server (or other computer or computer network)can: record the user's IP address and/or other identificationinformation from the user; collect user cursor motions, keystrokes,mouse clicks, etc. entered by the user over the same or other webpage atthe later time; combine these new interaction data with previousinteraction data collected from the user and stored with the user's IPaddress in a remote database; calculate a new human likeness scoreand/or a new human determination from the combination of new and olduser interaction data; and update the human likeness score and/or a newhuman determination stored within the user's IP address in the databaseaccordingly. Alternatively, the remote server can: execute Blocks of themethod as described above to generate a second human likeness score forthe user based on new interaction data entered by the user at the secondtime; aggregate, average, or otherwise combine the new human likenessscore of the user with one or more previous human likeness scores of theuser; generate a new human determination from the aggregate humanlikeness score; and update the human likeness score and/or humandetermination for the user stored within the user's IP address in thedatabase accordingly.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changesmay be made to the preferred embodiments of the invention withoutdeparting from the scope of this as invention defined in the followingclaims.

1. A method for distinguishing a human user from automated software, themethod comprising: receiving a request from a publisher for a humanlikeness score of a user accessing a web page through a web browserexecuting on a computing device; based on the request, collectingidentification data of the user; collecting a cursor motion entered bythe user into the web browser; extracting a noise component from thecursor motion; identifying a motion geometry in the cursor motion;accessing a noise model defining input noise characteristics of cursorinputs previously entered into graphical user interfaces by knownhumans; accessing a motion model characterizing cursor motion geometriespreviously entered into graphical user interfaces by known humans;calculating a human likeness score of the user based on a comparison ofthe noise component to the noise model and based on a comparison of themotion geometry to the motion model, the human likeness score lyingwithin a continuum of human likeness scores; and associating theidentification data of the user with a human determination based on thehuman likeness score falling within a range of human likeness scorescorresponding to humans.
 2. The method of claim 1, wherein collectingidentification data of the user comprises collecting an InternetProtocol address of the computing device; and further comprising, inresponse to the human likeness score falling within the range of humanlikeness scores corresponding to humans, storing the Internet Protocoladdress of the user in a database of Internet Protocols addresses ofother users associated with human determinations.
 3. The method of claim2, wherein storing the Internet Protocol address of the user in thedatabase comprises storing the human likeness score of the user with theInternet Protocol address of the user in the database; and furthercomprising retrieving the human likeness score of the user from thedatabase in response to receipt of a request from a second publisher forthe human likeness score associated with the Internet Protocol addressof the user.
 4. The method of claim 1, further comprising: collecting asecond cursor motion entered by the user into the web browser over asecond web page distinct from the web page; extracting a second noisecomponent from the second cursor motion; identifying a second motiongeometry in the second cursor motion; calculating a second humanlikeness score of the user based on a comparison of the second noisecomponent to the noise model and based on a comparison of the secondmotion geometry to the motion model; combining the human likeness scoreand the second human likeness score into an aggregate human likenessscore; and reassessing the human determination based on the aggregatehuman likeness score.
 5. The method of claim 1, wherein collecting thecursor motion comprises recording a set of discrete cursor motions inputinto the web browser; wherein extracting the noise component from thecursor motion comprises generating a characterization of noise acrossthe set of discrete cursor motions; and wherein calculating the humanlikeness score of the user comprises calculating the human likenessscore of the user based on a comparison of the characterization of thenoise component to the noise model and based on a comparison of motiongeometries for discrete cursor motions, in the set of discrete cursormotions, to the motion model.
 6. The method of claim 1, furthercomprising transmitting the human determination of the user to thepublisher.
 7. The method of claim 1, wherein collecting the cursormotion entered by the user into the web browser comprises recording thecursor motion entered by the user through the web browser in response toaccess of the web page by the computing device through the web browser.8. The method of claim 1, wherein accessing the motion model comprisesaccessing the noise model comprising a characterization of cursor motiongeometries previously entered into graphical user interfaces by knownhumans.
 9. The method of claim 8, wherein accessing the noise modelcomprises accessing the noise model comprising a signal-to-noise ratiopattern of cursor motion geometries previously entered into graphicaluser interfaces by known humans.
 10. The method of claim 1, furthercomprising associating the identification data of the user with anautomated software determination based on the human likeness scorefalling outside the range of human likeness scores corresponding tohumans.
 11. The method of claim 1, wherein collecting the cursor motionentered by the user into the web browser comprises recording at leastone of a cursor path, a gesture, a keystroke, and a cursor selectionentered into the web browser over the web page at the computing device.12. The method of claim 1, wherein identifying the motion geometry inthe cursor motion comprises extracting a speed of a cursor movementwithin the web browser, a direction of the cursor motion within the webbrowser, and a change of direction of the cursor motion within the webbrowser; and wherein calculating the human likeness score of the usercomprises calculating the human likeness score of the user based on adegree of similarity of the speed of the cursor movement, the directionof the cursor motion, and the change of direction of the cursor motionto a model human cursor movement, a model human direction of the cursormotion, and a model human cursor direction change, respectively, definedin the motion model.
 13. The method of claim 1, further comprisingsetting a custom range of human likeness scores corresponding to humansfor the user based on web traffic history of user; and whereinassociating the identification data of the user with the humandetermination comprises associating the identification data of the userwith the human determination based on the human likeness score fallingwithin the custom range of human likeness scores corresponding tohumans.
 14. The method of claim 1: further comprising, in response toreceiving the request from the publisher, generating a CAPTCHAcomprising a graphical interface and a first object and a second objectdepicted within the graphical interface; further comprising assigning avisual characteristic of the first object within the graphical interfaceto differentiate the CAPTCHA from a previously-generated CAPTCHA, thefirst object distinct from the second object by the visualcharacteristic; further comprising assigning an instruction for solvingthe CAPTCHA based on the visual characteristic of the first object;further comprising submitting the CAPTCHA to the publisher for deliveryto the user through the web page; wherein collecting the cursor motioncomprises receiving a cursor input provided by the user, through thegraphical interface presented through the web page accessed within theweb browser, to solve the CAPTCHA; further comprising determining anaccuracy of the cursor input in satisfying the instruction for solvingthe CAPTCHA; wherein identifying the motion geometry in the cursormotion comprises extracting an interaction pattern from the cursormotion; and wherein calculating the human likeness score of the usercomprises calculating the human likeness score of the user based on acomparison of the interaction pattern to an interaction pattern modelgenerated from interaction patterns of previous users and based on theaccuracy of the cursor input in satisfying the instruction for solvingthe CAPTCHA.
 15. A method for distinguishing a human user from automatedsoftware, the method comprising: receiving a request from a publisherfor a human likeness score of users accessing a web page affiliated withthe publisher; in response access of the web page by a user through aweb browser executing on a computing device, collecting a cursor motionentered by the user into the web browser; extracting a noise componentfrom the cursor motion; accessing a noise model defining input noisecharacteristics of cursor inputs previously entered into graphical userinterfaces by known humans; calculating a human likeness score of theuser based on a comparison of the noise component to the noise model,the human likeness score lying within a continuum of human likenessscores; and transmitting a human determination of the user to thepublisher based on the human likeness score of the user falling within arange of human likeness scores corresponding to humans.
 16. The methodof claim 15, further comprising collecting identification data of theuser and storing the identification data of the user and the humandetermination of the user in a database.
 17. The method of claim 16,wherein storing the identification data of the user and the humandetermination of the user in the database comprises, the human likenessscore of the user falling within a range of human likeness scorescorresponding to humans, storing the identification data of the user andthe human likeness score of the user in a database of identificationinformation of other users associated with human determinations.
 18. Themethod of claim 16, further comprising: collecting a second cursormotion entered by the user into the web browser over a second web pagedistinct from the web page; extracting a second noise component from thesecond cursor motion; calculating a second human likeness score of theuser based on a comparison of the second noise component to the noisemodel; combining the human likeness score and the second human likenessscore into an aggregate human likeness score; reassessing the humandetermination based on the aggregate human likeness score; and updatingthe database with the human determination based on the aggregate humanlikeness score.
 19. The method of claim 16, further comprisingretrieving the human likeness score of the user from the database inresponse to receipt of a request from a second publisher for the humanlikeness score of the user.
 20. The method of claim 15, whereinextracting the noise component from the cursor motion comprisescharacterizing a signal-to-noise ratio pattern of the cursor motion;wherein accessing the noise model comprises accessing the noise modelcomprising a model signal-to-noise ratio pattern based on cursor motionspreviously entered into graphical user interfaces by known humans; andwherein calculating the human likeness score of the user comprisescalculating the human likeness score of the user based on a degree ofsimilarity between the signal-to-noise ratio pattern of the cursormotion and the model signal-to-noise ratio pattern.